The invention relates to transaction processing, and more particularly to a transaction processing system of the client/server type in which a client process creates a mechanism in a server process that controls bi-directional transaction message traffic between the client and server processes.
A transaction has been defined as a logical unit of work by C. J. Date in his work, INTRODUCTION TO DATABASE SYSTEMS, Volume I (Addison-Wesley, September, 1985). Date particularly taught that a transaction in the database context consists of a sequence of operations by which a database is transformed from one consistent state to another consistent state. A transaction processing system guarantees that a transaction will either complete the transformation of a database into a new consistent state, or return the database to the consistent state at which the transaction began.
A particularly useful architecture for implementing transaction processing in distributed systems is the client/server model that is described in H. M. Deitel's OPERATING SYSTEMS (Addison-Wesley, 1990). In this model, clients denote service consumers in the form of client processes, while servers are processes that provide the services. In a typical database system that provides transaction-based access to a plurality of users, users enter database requests through client processes. The client processes engage the server process in the form of a database management system to service the user request according to a predetermined transaction protocol.
From the standpoint of client and server processes, transactions may be considered as "objects". As objects, transactions encompass the procedures and data necessary to satisfy a user request. As objects, transactions can be directly manipulated by clients and servers. The preferred mode of handling transaction objects is by messages that specify a particular type of manipulation. In this regard, a user request for reading records from a database may manipulate a transaction by specifying that the transaction must read the database and by providing parameters that establish where the reading is to take place, what records are to be read, etc. The transaction reports the outcome of the manipulation by returning a response message including the results of the operation.
Typically, objects are described by data structures that are referred to as "names". Current techniques of object-oriented programming recognize a "named processing object" as an object having a name and including one or more procedures.
A transaction message implies a source and a destination. A current database management system, such as the IMS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, distinguishes these end points by the use of logical terminals (LTERMs). An LTERM provides a queue where transaction output from the IMS product resides. Eventually, the IMS product makes the connection between the queue and a physical node that will receive the queued output. In the client/server model, the IMS product is considered the server process. Such database systems do not afford a client process with a mechanism to control transaction message flow by specifying the source and destination of a transaction message.
Viewed from another aspect, the LTERM capability of the IMS product provides a uni-directional (server-to-client) pipeline that can only be manipulated by the server. In this respect, an LTERM suggests the pipe structure used in UNIX.RTM. systems (UNIX.RTM. is a registered trademark of Novell, Inc.). Pipes may be objectified by names. They provide uni-directional, FIFO data transfer between processes and include the capability of interprocess synchronization. Two pipes oriented in opposite directions between client and server processes can provide bi-directional message flow, but entail two processing objects, only one of which can be manipulated by the client process.
Manifestly, the more time a server must spend in transaction message processing, the less efficient it will be in processing transactions. Accordingly, there is a need in transaction-based systems of the client/server type to provide a mechanism that will allow any client process to objectify a transaction and to manipulate the transaction object by messages in a bi-directional message pipeline.